Hi, thanks for the feedback. I added the changes you requested. Hope the grid implementation is correct

Would it make sense to only compute the value of and assign measured_size if known_dimensions is at least partially undefined? Or is it something that should be optimized by the compiler?

I understand absolute positioning is a rare case so it should not matter, and RunMode::ComputeSize is quite a short code path anyway being the extra potentially unnecessary operation, however I also think fully defined size for absolute item is a very common case (it is 100% of cases in our project at least), so it might be worth the branch

Would it make sense to only compute the value of and assign measured_size if known_dimensions is at least partially undefined?

Skipping computing size if a dimension is known is already implemented. As I'd skipping it if it's previously been computed and cached.

However, we still need to lay out the contents of that node if it has any. And the size of those contents are important as they may exceed the size of the container (in which case the node may scroll if configured to do so)

Would it make sense to only compute the value of and assign measured_size if known_dimensions is at least partially undefined?

Skipping computing size if a dimension is known is already implemented. As I'd skipping it if it's previously been computed and cached.

However, we still need to lay out the contents of that node if it has any. And the size of those contents are important as they may exceed the size of the container (in which case the node may scroll if configured to do so)

What I meant is this code: https://github.com/DioxusLabs/taffy/pull/878/files#diff-78a705bd422b6ec7ece906ca29973427ec10834766ca5bf1609459f0e4f539d5R2148
The only place the result of that code is used is the following line:
let final_size = known_dimensions.unwrap_or(measured_size).maybe_clamp(min_size, max_size);
And if known_dimensions.x and known_dimensions.y are both already defined, .unwrap_or(measured_size) would have no effect, effectively rendering the initial call to measure_child_size_both useless (it only computes size, it does not contribute to any side effect, at least with regards to the following call to perform_child_layout achieving all the same side effects anyway even with the lack of call to measure_child_size_both).

Ah yes, I see what you mean. That new computations isn't being skipped when it sometimes could be.